Features as Loosely Defined Method Fragments

1 Introduction In [1] is proposed a modular approach enabling developers to build customized project-specific methodologies from agent-oriented software engineering (AOSE) features. An AOSE feature is defined in [2] to encapsulate software engineering techniques, models, supporting Computer-Aided Software Engineering (CASE) tools and development knowledge such as design patterns. It is considered a stand-alone unit to perform part of a development phase, such as analysis or prototyping, while achieving a quality attribute such as privacy. Another method for building customized methodologies – OPEN [3] – includes the notions of Work Units, Work Products, Producers, Stages, and Languages. We can define an AOSE feature in terms of these notions as a Work Unit performed by one or more Producers in support of a specific software engineering Stage resulting in one or more Work Products represented in the respective Languages. For example, we can identify the feature of goal and role modelling performed by a domain engineer in support of the requirements engineering stage and resulting in goal models and role schemas. Analogously, we can identify the feature of simulation performed by a domain engineer and system architect in support of the rapid prototyping stage and resulting in the executable constructs of the JADE agent platform represented in the Java language. Both of the features mentioned support the quality goals of adequacy and correctness of the requirements captured. According to [3], a work product is any significant thing of value (e.g., document, diagram, model, class, or application) that is developed during a project. A language is the medium used to document a work product. A producer is anything that produces (i.e., creates, evaluates, iterates, or maintains), either directly or indirectly, versions of one or more work products. A work unit is defined as a functionally cohesive operation that is performed by a producer. A stage is a formally identified and managed duration of time. Differently from OPEN [3], we do not regard it as necessary to rely on the formal metamodel of method fragments. As has been demonstrated by our earlier work [1, 2, 4], and by the forthcoming book [5], informal approach to methodology composition works equally well and is more likely to be adopted by industry. 2 The conceptual space In place of a formal metamodel, we define features based on an ontologically-founded conceptual space within which to view systems. Two kinds of entities inhabit the conceptual space: abstract entities and …